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(57) Abstract: i.A method for 'creating a digital certificate! for a user issued: by a reliant party, where the reliant party relies on an 
established cryptographic inixasOuctuxc by a registration or certificate authority is described. The rcgistrarion authority, typically 
a large financial or credit institution, has already performed the initial overhead steps necessary for a digital anthenticaticm syitem 
using a chip card. These steps include- miming and distributing the chip card, establishing that the key pair and card are given to 
the right person, and creating the certificate horary. The reliant party leverages this cryptograjMc jnfrastrucujie to Issue us own 
digital certificate and certificate chain to a user already having a chip card from the registration authority. Consequently, a user can 
hove additional digital certificates issued to him without having his chip (^'modified in any way. AU additional digital certificates 
created for a user are stored at atisef-sperifcme^ty arra 
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METHOD AND APPARATUS FOR LEVERAGING 
AN EXISTING CRYPTOGRAJPIIIC 
INFRASTRUCTURE 

5 

Backgro und of the Invention 

The use of chip cards, such as the Visa Smart Card™, is on the rise. A chip 
card is assigned to a user by an entity which typically has a pre-existing relationship 
with that user. The chip card contains or has access to a digital certificate to authorize 

1 0 ^ t * s< * s reIatjonshi P- Using a chip card to store the digital certificate and other 
information is an improvement over existing configurations in which the digital 
certificate is stored on the device, such as a PC, laptop, hand-held computer, mobile 
phone* arid so on; By putting information on a chip card, the digital "certificate is still 
Secure but now portable. The chip card can now, be used at stores, service providers 

1 5 ^* g ' s car rental a *F? si ? > » hotels, airline ticket offices, public phones, laptop modem 
outlets, and the like), and, in the near future/public chip card readers for dispensing 
cash. Essentially, the card, and the user digital certificate, can be used to benefit both 
the user in terms of convenience and to the 'cardVcertificate issuer in terms of 
increased business at any location that has a chip card reader. 

20 It is widely recognized in the chip card service industry that establishing and 

implementing the cryptographic infrastructure for wide-spread use of the chip card is 
: expensive and difficult to manage for a vast majority of companies and organisations. 
This cryptographic infrastructure includes creating and distributing the chip cards to 
the ****** verif y inE itotify of the.users, and issuing digital certificates, Common 
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standards for issuing and storing ojgital certifi^ 

Infrastructure and the DES shared key system. Establishing the initial framework and 
mfrastmcture is typically done by large banks and credit card organizations which 
have a large, established customer base whose members are already accustomed to 
5 carrying the bank's or organization's card. 

. . . . Althou S h ^*y? to ^ble entities which do not have the means or 

financial power to establish their own infrastructure to use an existing infrastructure, 
these means typically require that steps be taken by the user and typically involve 
modifying the chip card. From a business perspective, this is impractical and has 
10 limited success since users generally do not respond to requests or offers to upgrade 
or modify chip cards. Furthermore, the memory available on chip cards for.storing . 
digital certificates is limited and, therefore, can only accommodate a limited number 
of potential entities that can take advantage of the existing infrastructure. 

Therefore, it would be desirable to be able to leverage an existing 
1 5 cryptographic infrastructure so that additional digital certificates can be accessed by 
one chip card without having to store additional data on the card. It would be- 
desirable to do this without having to modify the chip card or notify and require 
actions taken by users of the chip cards. In other words, have additional digital 
certificates for a user added to the chip card and done so transparently to the. user. 
20 Theiadditional certificates should be capable of containing data signed by the entities 
leveraging the existing infrastructure. These entities should also be able to use their, 
own trusted roots and not have to rely on the trusted root of the entity which laid 
down the existing cryptographic infrastructure. 

: 2 : 
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Summary of the Invention 

To achieve the foregoing, methods, apparatus, and computer-readable media 
are disclosed which provide a way for creating a digital certificate for a user issued by 
a reliant party, where the reliant party relies on an estabhshed cryptographic... 
5 uirxastructure by a re^stration or certificate authority, thi^ 

typically a large financial or credit mstitutiort, has already performed the initial 
overhead necessary for a digital authentication system using a chip card. These steps 
mclude minting ^ 

are given to the right person, and creating the certificate library.. ^ 
10 leverages this cryptographic infrastructure to issue its own digital certificate and 
, certificate chain to a user already having a chip card from the registration authority, 
' v In one aspect of the invention, the reliant party derives a set of attributes for 

. \ m ^ ™ a ^ is .relevant to the reliant party, this attribute set is men signed by the! 

reliant party using the party's private key. This encrypted attribute set, the non- 
1 5 encrypted attribute set, and a user public key are contained in a user certificate. The 
user public key has a corresponding user private key which is on the chip card. This 
public/pri vate key pair was generated earlier by a card minter and distributed to the 
right individual by the registration -authority. The newly created digital certificate, 
created by the reliant party, is stored in a certificate library and is identified 
20 unique identifier and other parameters as belonging to the reliant party. The user chip 
card contains an address to a memory segment in the certificate library. At that 
address arc stored one or more digital certificates and certificate chains, all for a 
single card holder. 

• .:. : ' • : ; • ■ . / = . : 3.. • ■ , . . . , • ..: • i. • - - ■ 
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In another aspect of the invention, a method of authenticating a user . 

presenting a chip card to an entity, such as a merchant or seryice.provider, is 

described, A certificate library address is read from the chip card. At the certificate 
library, the entity provides additional parameters to identify a particular certificate 
5 needed by the entity to authenticate the user. Once the correct certificate is located it 
is returned to the reliant party so that they may authorize the card holder's attributes. 
The methods of traversing the certificate^ain are known in. the field. For^example, 
one such certificate chain is a Public Key Infrastructure (PKI). Another cryptographic 
infrastructure can be based on a DED shared key system. 

10 Advantageously, a reliant party can leverage an existing cryptographic 

infrastructure to implement its own digital certificates and certificate chains having its 
own trusted root. This can be done without modifying or adding data on the user, chip 
card; that is, it can be done t^usparently to the user. The existing certificate library 
can be used to store a reasonably high number of certificates for one user. This frees 

15 a reliant party f 

trusted root. Also, advantageously, the reliant party does not have to mint new chip 
cards or generate new public/private or shared secret keys for a user. It can simply 
Use the keys dr^y generated and distribute 
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Brief Des cription or the Drawls 

The invention will be better understood by reference to the following 
description taken in conjunction with the accompanying drawings in which; 
FIG. 1 is a diagram showing the various components of a single PKL 
5 FTG. 2 is a diagram showing a single chip card having access to multiple PKIs 

in accordance with one embodiment of the present invention. 

FIG. 3 is a diagram illustrating various components used in a certificate store 
configuration in accordance with one embodiment of the present invention! 

FTGS - 4A > 4S > mi ^ ow diagrams illustrating a process for establishing 
10 additional PKIs leveraging an existing cryptographic tnfrastructure and certificate 
, store in accordance with the one embodiment in the present invention. 



..rv 



5 
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Detailed PEsaairnoN " 

Reference will now be made in detail to a preferred embodiment of the 
mventibo. Ah example of the preferred embodiment is illustrated in the 
accompanying drawings. While the invention will be described in conjunction with a 
5 preferred embodiment, it will be understood that it is not intended to limit the 
invention to one preferred embodiment To the contrary, it is intended to cover 
alternatives, modifications, and equivalents as may be included within the spirit and 
scope of the invention as defined by the appended claims* 

Wben two parties interact on the Internet or any type of physical or wireless 
10 network, authenticating or verifying the identity of the consumer is a critical factor 
The process described below cannot proceed until it is fim established that the user 
receiving a newly minted chip card is who she says she is. Once this is done, a party 
. can produce a digital credential for the user. One way of issuing the user a digital 
certificate is to use the well-established Public Key Infrastructure (PKI). 

15 A single PKI is normally comprised of a certi ficate chain beginmng with a 
user certificate Cuser" is defined as consumer, client, or card owner/holder) which 
can reside either on the chip card or in a certificate library under the control of a 
certificate authority. Although the chip card may riot contain me cert^^^ 
contain, among other data, the user's private key. The corresponding public key is 
20 contained in the user's digital certificate. As mentioned, this certificate, and it's 
associated chain of certificates, can be stored on the card or in a certificate .library. 
For the purposes of illustrating the described embodiment, it is assumed that the 
certificate chain is stored in a certificate library. The benefits of storing it in a 
certificate directory or library are described below. 
. . . : .: 6 
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FIG. 1 is a diagram showing the various components of a single PKL Other 
standards such as shared-key DES can be used in place of PKI without significantly 
diverging from the present invention. A chip card 102 contains a user private key 104. 
and certificate library address identifier 1 06. The address is of a memory location in a 
5 certificate library (described below) wWch stores a certificate chain 10 

certificate in certificate chain 1 08 is a user digital certificate 1 1 0 that contains a public 
key 112 corresponding to private key 1 04. 

In the case of chip cards, this public/private key pair is generated by a key- 
generation program typically executed by a card minter at the card minter's. premises. 

10 The keys are generated securely on the chip card itself in such a way that the private 
key cannot be removed. Neither the card minter nor the customer knows the value of 
the private key and neither have a need to know. The key is securely stored on the 
card and its value unbeknownst to any party. However, the value.of the public key 
arid is given to a certificate authority and need not be kept secret and stored 6n the 

15 user's digital certificate. This process of minting and distributing the chip card and 
keys are steps that must be taken initially to establish a cryptographic infrastructure. 

User digital certificate 1 1 0 (the first certificate in chain 1 08) also contains 
attributes 1 1 4. This information is data on the user that is selected by and relevant to 
a particular registration authority, such as a bank, credit card company, airline, 

20 merchant, and the like. Some typical examples of attribute data 1 14 are user name, 
account number, registration authority or entity name (e.g., XYZ Bank, US Airline, 
Credit Card Company, etc.), and user date of birth. Essentially, it is data relating to 
the customer that the registration authority is willing to verify or back up. Also stored 
on| customer certificate 1 1 0 is an encrypted data segment 116. The data encrypted in 

25 data segment 1 1 6 tie attributes 114 to user public key 1 12 and thereby the user's 

i 
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private key in their possession. By encrypting data segment 116, it is being "signed" 
by the registration authority, for example, a Bank. The registration authority signs the 
data, in this example attributes 114 and user public key 1 12, using the registration 
authority's private key (not shown) thereby creating encrypted data segment 116. 
5 Naturally, the registration authority has access to its own private key and is not 
contained in certificate chain i 08. 



A second certificate in certificate chain 1 08 is the Bank certificate 11 8 which 
has components similar to user digital certificate 110. Certificate 1 1 8 contains a Bank 
public key 120 and attributes 1 1 5, attributes that are relevant to another entity, such as 
1 0 a trusted root, having a certificate in certificate chain 1 08. An encrypted data segment 
122 in Bank certificate 118 is attributes 115, this time encrypted or signed using a 
public key belonging to a trusted root, such as banking associations.^., Visa) or a 
government agency. This root is an entity that both the merchant and Bank trust in, 
simply, telling the truth about the identity of certain parties. The merchant maynot : 
15 necessarily trust the Bank in that it may not have complete confidence in the Bank's ! 
identity. However, the merchant does trust the root, and if the root is willing to verify 
the Bank's identity, the merchant will trust the Bank and : ultimately the card bolder. 

There can be additional certificates belonging to other entities between the 
Bank and the root. The merchant can traverse up certificate chain 108, one certificate 
20 at a time, until it reaches an encrypted data segment signed by a root trusted by the 

merchant. The string of certificates, or certificate chain, and the configuration of the : 
certificates described above are well-known in the field of digital signatures and 
certificates. A single certificate chain as described above can be referred to as one 
PKI as it authenticates one type of relationship, such as the banking relationship. 
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The verification process using the single PKI configuration described above 
starts with the user certificate and ends with a root certificate which the reliant party 
or not trust A user gives her Bank chip" card to a merchant for a purchase. 
Suppose the merchant is not an affiliate of the Bank and that the merchant does not 
5 trust or, more specifically, does not recognize the Bank. Using certificate library 
address 106 on the card and additional parameters, snch as an appropriate certificate 
identifier, the merchant gets access to certificate chain 108. It is assumed that the 

merchant has the necessary equipment, such as a chip card reader, and software to 

access and process digital certificates, such as the standard PKI or standard DBS 
10 software. The merchant reads user public key 112, attributes 114, and encrypted data 
segment U 6 in user certificate 110. 

The merchant now needs to see who signed encrypted data segment 11 6. It 
does this by retrieving a public key from the se^hd certificate m the chain; in the - 
above example, this is Bank public key 120. Encrypted data segment 116 is 
15 decrypted using public key 120. If the resulting decrypted data segment matches the- 

on to the next certificate in the chain. At this stage, the merchant knows thatat least 
the Bank has verified, essentially, that the user is who she says she is. But the 
merchant may not trust the Bank, so it continues up the chain. 
20 ™ emCTC ^l°°teatthene*^ 

united entity. This entity has its ' public key in its certificate which the merchant 
can jise to decrypt the encrypted segment in the Bank's certificate. If the decrypted 
" segment rnatches the normal text of ^ U4 in the Bank certificate, the entity is 
ha* verified, OT a similar manner, that the Bank is who the Bank says it is. However, 
25 the merchant may not trust the entity, and continues down the certificate, chains a ■ 



9 
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similar manner At some i point the merchant must trust some entity. This entity, is . 

referred to as the trusted root. When the merchant reaches the trusted root, it has 
traversed one PKI and the process of traversing the certificate chain stops. "? [ 

The certificate of the root trusted by the merchant is contained in the.PKI 
5 software that the merchant has in his system. At this stage, the merchant can prese.ut 
the user with a "challenge." A challenge is essentially a string of text chosen by the 
merchant. The user is then required to encrypt this challenge using her private key 
104 on the chip card. The merchant then attempts to decrypt the data using the user's 
public key on the user certificate. If this is successful, the merchant can be assured 
10 that the user is the legitimate certificate holder and that the uset certificate belongs to 
that user. The merchant can now confidently accept the chip caid from the user for 
-completing a transaction. 

The certificate authority here is the entity that creates the card holder 
ceVtificate chain under the control of a registration authority, such as the Bank. In 

entity that issues the chip card to the user through a card minter, has to perform some 
initial overhead before issuing the card to the user and laying down the cryptographic 
infrastructure described above. The registration authority must verify the identity of 
the user. By doing so it validates that the person holding private key 1 04 on chip card 
20 1 02, that corresponds to public key 1 1 2 in user certificate 1 1 0, is, essentially, the right 
person. The registration authority typically has an existing relationship with the card 
hojder to who it is issuing a chip card. The chip card needs to be delivered to the card 
holder in a trusted manner, for example, through certified mail. 

This is an important "overhead" step that must be taken before the user is 
25 issued the chip cafd and a public/private key pair. The strength of user certificate 1 10 

' * *:''.' : : 10 : . v; ........ ... 
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depends on the strength of this user identity verification p^onn^ at Wtioie when 
topr^atekeyisissuedfe^^ Bydoifig . 
this, the registration authority i B laying down a cryptographic infi^tmctur^on 
which the registration authority can build one PKI. Laying down this infiBstructure . 
5 and managing this life cycle, i.e., minting the chip card, issuing and storing^ user 
certificate, veriiymgthattherightperso^ 

an expensive and tune^nsuming process: Typically, operations of this scale are 
performed by large financial institutions having an established customer base, such as 
banks, credit card companies, credit unions, and large corporations. 

10 The present invention is a method in which additional PKls can be created 

using an existing cryptographic infrastructure as a foundation. This would allow for 
true and complete PKIs that can be used by smaller entities. By leveraging such an 
infrastructure, an entity can conduct their own certificate chain verification, as 
• described above in the case of the Bank and merchant, using their own user' attributes: 
15 (di-fferent from attributes 114) and trusted root. If the cryptographic infrastructure laid 
down by the registration authority is to be leveraged, it is more practical to store all 
^certificate chains (PKIs) in a high-speed certificate library instead of on the chip 
eard. This reduces the data needed on the card, eliminates the need to modify the card 
when adding new PKIs, and allows for a high number of certificates for a user. 

the registration authority's cryptographic mfrastructure and verification of the user . 
keypair. Since the user's public/private key has been verified, the user's publickey . . 
can now be "signed," by the new entity with attributes that suit the new entity. By 
si ^S* e ^s public key an 
25 tiewusercertificateand.her.ce.anewPKI. Additional PKIs can be rapidly deployed 

11 
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to a user without having to modify the user's chip card. The additional certificate 
chains representing the new PKIs are simply stored in the certificate library at address 
106 on the user chip canL Thus, the certificate library is leveraging the library 
address on the chip card* 
5 FIG. 2 is a diagram showing a single chip card having access to multiple PKIs. 

Chip card 102 stores a certificate library address 106 which can access a certificate 
library 202. At certificate library address 106 axe stored multiple PKIs all having the 
same user public key, shown as Public Key A. As described above, Public Key Aand 
corresponding private key 104 were verified initially to belong to the correct user by 
10 the registration authority. This is the initial overhead or due diligence performed by 
this registration authority. Any number)* of PKIs can be Padded to certificate library 
202. The trusted root in each PKI can be the same as or different from any other 
trusted root The trusted root is established via a relationship between the entity 
creating the PKI and the root 

15 FIG- 3 is a diagram illustrating various components used in a certificate store 

configuration in accordance with one embodiment of the present invention. A 
registration authority 302, such as the Bank in the above example, typically has a 
previously established relationship with a card holder. Registration authority 302 
authorizes a certificate authority 304 to create a digital certificate 306 for 

20 authenticating a relationship as described above. Alternatively, the card holder can 
have a relationship with a reliant party 308, such as a merchant or service provider. 

The card holder typically receives a chip card 31 6 through a trusted process, 
such as certified mail, via a card rninter, from a registration authority, also referred to 
as a primary party- The card holder uses a card holder system 3 1 0 to interact' with a 
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reliant party 308, such as in a merchant store or at a PC. Card holder system 3 1 0 is 
airy type of internet access device 3 1 2 coupled with a chip card iirterfacc deyice.3 1 4* 
capable of reading card 316. Internet access device 3 1 2 can be^ for example, a PC, a 
set-top box, a ceU phone, or a hand-held computer. Chip card 316 contains an 
5 application 3 1 8 that can include a unique address for a memory location in a 
certificate library directory 202. Certificate store application 3 1 8 also include* a 
private key. The chip card can also be protected by a PIN or other method of 
.." t ~ . ' '"^cCiolderver^^pn. ' ' \. .\' tmm ^...."..Y. ,! . v 

Certificate authority 304 is an entity capable of generating and storing a user 
10 digital certificate and a certificate chain after receiving instructions froifi a registration 
authority or a reliant patty. As described above, a private key is stored on chip card 
316 by a card minter on behalf of a registration authority or a primary party The 
public key and other attributes are signed by a certificate authority 304 (iii many cases 
the same as the registration authority) to create a certificate 306 which is stored in a 
15 certificate library directory 202, In the described embodiment, certificate authority 
304 communicates with the card minter and registration authority 302 through a 
proprietary protocol, In the described embodiment, communications with certificate 
library directory 202 are based on the Lightweight Directory Access Protocol (LDAP)! 
The card minter generates the public/private key pair on the card and communicates 
20 with the certificate authority through a proprietary protocol. In the described 

embodiment, reliant party 308 uses LDAP to communicate with certificate library 
directory 202 and uses HTTPS to communicate with card holder system 3.1 0. As 
described above, card holder system 310 is a combination of hardware, and software 
that includes chip card reader 3 14 used to connect to reliant parry 308. Card holder 
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. system 310 (which can be mobile) facilitates coihrnimication between the card holder 
and reliant party 308 through EMV and HTTPS protocols. 

As described above, reliant party 308 does not .have to verify the correct 
identity of the card holder or lay down the cryptographic infrastructure necessary for. a 
5 PKX This has already been done by the primary party/registration authority. 

However, the reliant party, such as the merchant, does have to authenticate its own 
relationship with the card holder by signing her public key, thereby issuing the card 
holder a separate digital certificate and certificate chain. The reliant party must 
contract with the certificate authority to do so. In this way the reliant party can create 
10 new certificates without impacting the card holder, by borrowing the cryptographic 
iin^structure» . ".. '[. 

Certificate library directory 202 is an LDAP server able to store the certificate . 
so that a reliant or primary party can authenticate a relationship between the party and 
auser exists. For example, a merchant can read an address on the card, access a 

15 memory location in the certificate library, and determine whether the card holder has 
a digital certificate issued by that merchant or recognizable to that merchant . In the 
described embodiment, certificate library directory 322 relies oh LDAP to 
communicate with reliant party 308 and certificate authority 304. Chip card 3 16 cart 
store credit, debit and other stored applications. Chip card 31 6 can also have 'Value 

20 a4ded" apphcations to provide reliant party 308 and the user with other applications 
ra" addition to user authentication. Since chip cards are resource^onstrained devices, 
it is desirable to minimize data on the chip card. 

The certificate store configuration of the present invention offers the ability to 
support numerous PKIs using a single private key and certificate library address 

14. 
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which combined make up approximately two kilobytes of memory cm the chip card. 
As described above, certificate store application 3 1 8 on card 3 1 6 represents : a private 
key and an address that links it to a digital certificate containing a public key in 
"' certificate UTjrary directory 322. If reliant party 308 wants to authenticate^the.card " 
5 holder, it can access card application 3 1 8, request an appropriate certificate from 
certificate library 202 by appending LDAP query parameters to the address on the 
card, and traverse the certificate cham usmg me process described abpy 
certificate exists, it is accessed so the reliant party or primary party can validate the 
card's private key. This process is described in greater detail below 

10 fid. 4 is a flow diagram illustrating a process for establishing additional PKIs 

; leveraging an existing cryptographic in^tructure and certificate, store in accordance 

^ one embodiment in the present invention. The following assumptions are 

mkdc: 0 ) a chip card has been issued to a card holder; (2) the card contains a private 
key; (3) a digital card holder certificate generated on behalf of the reliant party and 
15 issued by a registration authority is stored in a certificate library; and (4) the user has 
presented his card to a reliant parry (e.g.. an airline frequent flyer member is accessing . 
a secure airline web site to access special services). 

At a step 402, a secure, authenticated and dedicated connection between a 
reliant party, e.g.. the airline, and an internet access device ('TAP") is established. 
20 Thjs connection between the reliant party and IAD {not the user) can be an SSL 

: Version 3 connection or a Transport Layer Security (TLS) connection. With SSL or 
TLS 3 the connection is secure thereby preventing other parties from eavesdropping. 
The reliant party can also have a certificate used by the IAD to authenticate the reliant 
party. In another preferred embodiment,, greater control using SSL or TLS can be 
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used with a card bolder system certificate thereby ensuring that the request originated 
from a legitimate system. If the certificate library directory retains maximum control 
over the certificates, the chip card does not need to have an authentication certificate* 
If the reliant party can authenticate the card holder by checking the certificate library 
5 for the correct digital certificate each time the card holder accesses the reliant parry, 
there is no requirement to expose a public key outside of the certificate library 
directory. 

At step 404, once a secure and authenticated connection has been established 
between the IAD and the reliant party, the IAD accesses the chip card (through a card 
10 reader) to read the unique LDAP address for a certificate library from that card. The 
address can be in hie following format: 
LDAP://Idap.Certijicatid.ibrary.coin/o~Membert^ 

At step 406, the IAD, now in possession of the LDAP address, proceeds to 
contact the reliant party and requests access to a privileged service. It does so by first 

15 providing the reliant party with the U)AP address where^ 

and PKIs are stored. By providing the reliant party with the LDAP address of the card 
holder/ the reliant party can check to see whether the user has an airline-issued digital 
certificate and whether it should allow access to its restricted services!. However, 
before the certificate library allows the reliant party to pass it the LDAP address, there 

20 are security and authentication measures taken between the two entities beginning 
with step 408. 

At step 408, the reliant party creates a secure authenticated connection with 
the certificate library using, for example, SSL Version 3 or TLS, with certificates for 
mutual authentication. This connection should be secure and authenticated since 

16 
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competitively sensitive information may be transferred between the reliant party and 
the certificate library. The certificate library may want to ensure that it is giving 
information to the proper reliant party; and not to, for example, a competitor of the 
reliant party. The certificate library can also be charging a fee for access to its library 
and may want to ensure that a "member 7 ' reliant party is getting the ^formation. 

At step 41 0 > the reliant party creates an authenticated session "on top of the 
connection with, the certificate library. This can be done using an LDAP Version 3 
bind request, which, in turn, uses the Simple Authentication and Security Layer 
(S ASL) authentication framework. Although the reliant party has already created a 
secure, authenticated connection with the certificate library, this session ' 
authentication allows for features Uke variable pricing and liability options for the 
reliant party, as well as for more flexible technical configurations! For example, the 
reliant party may only have a secure connection to a proxy server. In this case, the 
reliant party would use the LDAP bind authentication for access to the actual 
certificate library server. The reliant party may also have the ability to modify the 
type of authentication provided in order to vary the price and detail of the information 
requested. In another preferred embodiment, this second bind request for creating an 
authenticated session may not be necessary or desirable. 

At step 412 the certificate library directory responds to the reliant party's bind 
request The library typically responds with a message indicating that the bind was 
successful or that it failed. The library directory makes this determination based on 
access control rules defined by the certificate library directory administrator. 
Assuming the authentication bind was successful, the reiiaiit party requests 
information, such as whether the user has a digital certificate issued by the reliant 
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party, at the memory location indicated by the ID AP address. The reliant party does 
so by appending LDAP parameters to the request. 

If either bind requests fail, the chip card holder is not authenticated and, 
consequently* may not be allowed access to reliant party services; The reliant party 
5 makes this deteimmation by using the LDAP address contained in the chip card as the 
base of a query requesting information from the certificate library. The request could 
also be for other information such as the status of the card holder's membership, the i 
card holder's membership level, account information* or a copy of the certificate. 

At step 4 1 4, the certificate library responds to the query made by the reliant 
10 party at step 412 by supplying the requested data or any other appropriate response. 
This can include, for example, a message stating that the user certificate has been .' 
. revoked or never existed. In the described embodiment, the certificate library has its 
own information access rules as to the type of information for which each, reliant party 
may ask and details of the response to be returned. Thus, a highly tailored 6r , 
1 5 customized information and authentication service can be provided to the reliant party 
which allows the reliant party, such as a merchant or airJine, to provide specialized 
services to its customers. . 

At step 416, the reliant party presents an authentication challenge to the user. 
At this stage, the reliant party has irrformatiori on the card holder, specifically that the 
20 card holder has an appropriate certificate and, thus, the attributes on the certificate and 
user public key. The reliant party must detenriine if the card holder is allowed to , 
. access information (or withdraw cash, make a purchase, etc.) based on the reliant 
party's own access control rules (separate from those of the certificate authority). 
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The reliant party now authenticates the card holder's clam pf identity by 
authenticating Hie private key on the chip card, to do this, the reliant party sends a : : 
challeixge via the IAD to the chip card. The challenge, a text string chosen by the . 
reliant party, is sent in the form of a signing request. The chip card receives the text 
5 string unencrypted. 

Jjx one embodiment, LDAP assumes X-5Q9 certificates are the.primarymeans. 
to authenticate entities. However, if the certificate library directory is to retain central 
control of the certificates, the information stored in the certificate should be limited or 
&e certificate should have a comparatively short duration! Other forms of secret keys, 
1 0 both symmetric and asymmetric should be considered in light of the business 
requirements of the reliant party. 

At step 41 8, the card holder may be prompted for a PIN to verify that the card 
holder is the owner of the chip card. This can be done if the chip card application and 
the IAD support card holder verification. This may not need to be done since the 

15 original registration authority has verified the identity of the card holder as part of the 
initial overhead of laying down the cryptographic infrastructure. At step 420 the card 
application signs the challenge sent by the reliant party using with the private key on 
the chip card. The resulting encrypted text string is returned to the reliant party via 
the IAD. At step 422 the IAD forwards the signed challenge from the chip card to the 

20 reliant party. At step 424 the reliant party opens a second authenticated bind request 
with the certificate library directory. This second authenticated bind request could be 
either a second session or a proxy bind using the original session established earlier. 
Upon receiving the request the certificate library uses the card holder public, key to 
decrypt the response. If the decrypted response matches the original challenge, the 
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certificate library can be assured the card holder and the certificate are tied together. \ 
It is also possible to have the reliant party decrypt the challenge if the certificate is 
resumed in the original request. 

At step 426 me certificate library dir^ 
5 reguest If the request is successful, the reliant party can be assured that the identity 
of the card holder is legitimate (i.e., the card bolder is who he says he is). In 
described embodiment, the library directory access control rales will typically allow 
only positive or negative responses to the card: Assuming the library directory access 
control rules reply with a positive response, the reliant party can be assured of the 
10 card holder's identity. 

At step 428, the reliant party may now grant privileged access to the card 
holder according to the reliant party's access control rules. For example, at this point, 
the card holder.can access the airline web site or make a purchase from a merchant; If 
the reliant party requires data to be signed by the chip "card application, the certificate 
1 5 library can either return a public key from the certificate chain to the reliant party 
allowing the reliant party to validate the signature. 

Although the foregoing invention has been described in some detail for . 
purposes of clarity of understanding, it will be apparent that certain changes and 
modifications may be practiced within the scope of the appended claims. 
20 Furthermore, it should be noted that there are alternative ways of implementing both 
the process and apparatus of the present invention. For example, although a PKI 
infrastructure using public and private keys is used to illustrate the described . 
embodiment, other systems, such as the DES shared secret key system, can be. used. 
In another example, although the certificate library server is described as an LDAP 
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server, otter access protocols and server types can be used to implementthe 
certificate library. Accordingly, the present embodiments are to be considered * '. 
illustrative and not restrictive, and ^invention is not to be limited to tbe details 
' given herein, but may be modified within the scope and equivalents of the appended . 
5 claims. 
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Claims 

What is claimed is: . 

1. Amethod of creating a digital certificate for a user comprising: 

deriving a first data set containing data pertaining to the user and useful to an 
5 i^uing party issuing the digital certificate; 

associating a user public key with the first data set thereby creating a second 
data set, the user public key and a corresponding user private key both generated and 
authenticated before the creation of a digital certificate by the issuing party; 
encrypting the second data set using an issuer private key; 
creating a digital certificate containing the user public key, the firet data set, 
and the encrypted second data set, the digital certificate being identifiable by an 
issuing-party identifier; and 

storingthe digital certificate at a user-allotted memory segment of a certificate 
library, in which one or more digital certificates fprthe.usercan .be stored at the user- 
15 allotted memory segment 

2. A method as recited in claim 1 further including associating a certificate chain 
with the digital certificate, the certificate chain having a trusted root, the trusted root 
being different from other trusted roots stored at the user-allotted memory segment. 

3. : A method as recited in claim 2 further including using the Public Key 
Infrastructure (PKI) to configure the digital certificate and the associated certificate 
chain, thereby creating one PKI, and storing two or more PKIs at the user-allotted 
memory segment of the certificate library. 

4. A method as recited in claim 2 further including using the Digital Encryption 
Standard (DES) shared-key system to configure the digital certificate and the 
associated certificate chain, and storing two or more DES shared-key systems at the 
user-allotted memory segment of the certificate library. 
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5. A method as recited in claim 1 further including accessing the digital 
certificate in the certificate library using the issuing-party identifier. 

6. A method as recited in claim 1 further including accessing the digital 
5 certificate in the certificate library using a merchant-specific identifier. 

7. . A method as recited in claim 1 further including determming which party 
signed the encrypted second data set by retrieving a public key from another digital 
" certificate. 

10 

8. . A method as recited in claim 7 further including decrypting the encrypted 
second data set and comparing the decrypted second data set with the second data set. 

9, , A method as recited in claim 1 further including presenting a text string to be 
15 signed by the corresponding private key. 

10; A method as recited in claim 1 further including laying down a.cryptographic 
infrastructure before the issuing party issues the digital certificate, wherein the 
cryptographic im'rastructure includes: 

20 : generating and authenticating the user public key and corresponding private 
key; 

creating the certificate library; and 
allocating the user-allotted memory segment. 

25 11; A method as recited in claim 10 further comprising minting and distributing a 
chip card to a User. 

12: A method as recited in claim 1 wherein the certificate library is a Lightweight 
Directory Access Protocol (LDAP) server 



30 



13. A method of authenticating a user presenting a chip card to an entity, the 
method comprising: 

reading a certificate library address from the chip card; 
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accessing a certificate library memory segment using the certificate hbrary 
address; 

searching the certificate library memory segment for a digital certificale 
haying an entity identifier and followed by a digital certificate chain; and 
5 traversing the digital certificate chain begmning with the digital certificate 

tagged by the entity identifier until a trusted root certificate is reached. 

14. A method as recited in claim 1 3 further including storing a user private key 
and the certificate library address on the chip canL 

IO 

.15.. . A method as recited in claim . 13 wherein the certificate library is a . 
Lightweight Directory Access Protocol (LDAP) server. 

16. A method as recited in claim 13 further including storing additional digital 
15 * certificates having different entity identifiers at the certificate library memory 

segment. 

17. A method as recited in claim 16 further deluding associating additional digital 
certificate chains with the additional digital certificates, each certificate chain having 

20. its own trusted root. 

18. A method as recited in claim 13 wherein searching the certificate library 
memory segment for a digital certificate further includes using specific parameters 
further specifying which portion of the certificate library memory segment contains a 

25 digital certificate issued by the entity. 

19. A certificate library having a plurality of user-specific memory segments, each 
user-specific memory segment storing a plurality of digital certificates issued to a 
user, each digital certificate identifiable by an issuer-identifier and being associated 

30 with a trusted root certificate and each digital certificate having the same user public 
key. 
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20. A computer-readable medium containing programmed instructions arranged to 
authenticate a user presenting a chip card to an entity, the computerate me di U m 
including programmed instructions for: .. 

reading a certificate library address from the chip card; 

5 : • accessing a certificate library memory segment uang the certificate library '. 
address; 

searching the certificate library memory segment for a digital certificate . . 
haying ah entity identifier and followed by a digital certificate chain; and 

. ttBvw »W8 distal certificate chain begirining with the digital certificate 
10 tauBd by tf» entity Identifier until a in^ted root certificate is reached. 
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